1. The Field of the Invention
The present invention relates to network communication technology, and more specifically, to mechanisms for increasing the accuracy and efficiency of admission control for data streams.
2. Background and Relevant Art
Computer networks have enhanced our ability to communicate and access information by allowing one computer or device (hereinafter both referred to as a “computing system”) to communicate over a network with another computing system using electronic data. When transferring electronic data between computing systems, the electronic message will often pass through a protocol stack that performs operations on the electronic data. The Open System Interconnect (“OSI”) model is an example of a networking framework for implementing a protocol stack.
The OSI model breaks down the operations for transferring electronic data into seven distinct “layers,” each designated to perform certain operations in the data transfer process. While protocol stacks can potentially implement each of the layers, many protocol stacks implement only selective layers for use in transferring electronic data across a network. When electronic data is transmitted from a computing system, it originates at the application layer and is passed down to intermediate lower layers and then onto a network. When electronic data is received from a network it enters the physical layer and is passed up to higher intermediate layers and then eventually received at the application layer.
The application layer, the upper most layer, is responsible for supporting applications and end-user processes. An intermediate layer incorporated by most protocol stacks is the transport layer, which at the very least functions to multiplex application data into transport layer segments for delivery to lower layers and to demultiplex transport layer segments into application data for delivery to applications. The User Datagram Protocol (“UDP”) is an example of a protocol implemented at the transport layer that does little more than multiplex/demultiplex data for compatible transfer between applications and networks. Another common protocol implemented at the transport layer is the Transmission Control Protocol (“TCP”), a connection-oriented protocol that can also provide the features of end-to-end error recovery, resequencing, and flow control to the application layer.
UDP is particularly well suited for transferring real-time data, such as, for example, audio and video data (“A/V data”), as a steady and continuous stream (frequently referred to as “streaming”) between computing systems. Since output of real-time data often includes refreshing previously received real-time data, some loss of real-time data (e.g., such as the inherent data loss in many networks) from a real-time data stream is not critical. For example, when video data for a video frame is not received, a display screen may appear to momentarily flicker but is then refreshed when updated video data is received. Accordingly, UDP is frequently used to transfer real-time data streams between computing systems in Home Network, Local Area Network, and Wide Area Network environments.
Unfortunately, UDP has no built in mechanism for congestion control. Thus, a computing system utilizing UDP to transmit a real-time data stream typically cannot detect when transmission of the real-time data stream is being degraded due to network congestion. Likewise, a computing system utilizing UDP to transmit a real-time data stream typically cannot detect when the real-time data stream is causing network congestion that degrades other (possibly also real-time) data streams. Thus, it may be that a real-time data stream is transmitted onto a network with other existing data streams thereby potentially degrading the quality of all the data streams.
For example, when a 10 Mega-bit per second (“Mbps”) Ethernet Hub is supporting an existing 6 Mbps High Definition Television data stream and another 6 Mbps High Definition Television data stream is initiated, both data streams may suffer from high delay, jitter, and packet loss. Further, since the transmission speed of UDP is only constrained by the rate at which an application generates data and the capabilities of the source (CPU, clock rate, etc.), it would not be uncommon to have a number real-time data streams transmitting data at high bit rates at any given time. Although, TCP has a congestion control mechanism, the TCP congestion control mechanism is not well suited for real-time applications, such as, for example, those applications that transmit A/V data streams. The TCP congestion control mechanism reduces the bit rate when one or more data links between a sending computing system and a receiving computing system become excessively congested. However, a reduction in bit rate can degrade real-time data streams, which can tolerate some packet loss but typically require a minimum bit rate.
It may also be that when a network becomes congested, one real-time data stream gets a disproportionate amount of bandwidth (commonly referred to as the “Ethernet Capture Effect”). Thus, a newer real-time data stream could possibly “take-over” bandwidth from an existing real-time data stream. This may leave an existing user of an existing real-time data stream dissatisfied. An initiating user of a newer real-time data stream may not have actively desired to degrade the existing real-time data stream. However, the initiating user may have no way to determine if the network could support both real-time data streams prior to initiating the newer real-time stream.
Accordingly, probing techniques have been developed to attempt to determine if a network has sufficient available bandwidth to support an A/V data stream or other type of real-time data stream before allowing the A/V data stream or other type of real-time data stream onto the network. One probing technique includes a transmitting computer system passively detecting a transmitting side data load. The transmitting side data load is subtracted from the transmitting side bandwidth capacity, such as, for example, 10 mega-bits per second (“Mbps”), to calculate the available transmitting side bandwidth. When the available transmitting side bandwidth is greater than a requested application bit rate, the available transmitting side bandwidth is viewed as sufficient to receive the application data stream. Depending on network configuration, the transmitting side computer system also sends instructions to the receiving side computer system to calculate the available receiving side bandwidth. When the available receiving side bandwidth is greater than the requested application bit rate, the available receiving side bandwidth is viewed as sufficient to receive the application data stream.
Another probing technique includes a transmitting computer system transmitting a first packet-pair data packet and then subsequently transmitting a second packet-pair data packet, both via a network data path, to a receiving computer system. The receiving computer system receives the first packet-pair data packet at a first reception time and the second packet-pair data packet at a second reception time. Based at least on the difference in the first reception time and the second reception time, the bottleneck bandwidth of the network data path is estimated. When the bottleneck bandwidth is greater than the requested application bit rate, the available network data path bandwidth is viewed as sufficient to receive the application data stream.
Yet another probing technique includes a transmitting computer system identifying parameters for configuring trains of data packets to simulate transmitting the application data stream at the requested application bit rate. The transmitting computer system temporarily transmits a train of data packets in accordance with the identified parameters to simulate transmission of the application data stream. The receiving computer system receives at least some of the data packets in the train of packets. The receiving computer system calculates (e.g., based on reception time intervals) whether the train of data packets caused the network data path to transition into a congested state.
It may be that a number of these probing techniques are utilized in combination as part of an admission control function to determine whether introduction of a new real-time data stream onto a network would significantly degrade other (possibly also real-time) data streams already on the network. However, many real-time data streams are variable bit rate (“VBR”) data streams. That is, the actual bit rate at any given time can vary (possibly significantly) between zero and a specified maximum bit rate. Thus, there is always some possibility that at the time probing occurs, one or more real-time data streams are transmitting at less than their maximum bit rate. Accordingly, the results of probing a network that carries VBR data streams may not be entirely accurate.
For example, on a network that can support an aggregate bit rate of 10 Mbps, probing results may indicate that existing data streams are consuming 4 Mbps, and thus, 6 Mbps is available. However, if at the time of probing, the 4 Mbps is being consumed by a VBR data stream having a bit rate in a range between 3 Mbps and 6 Mbps, 4 Mbps is not an accurate indication of the available bandwidth. That is, although probing results indicate that 6 Mbps is available, introducing a new data stream at a bit rate greater than 4 Mpbs (the available bandwidth when the VBR data stream is at its maximum bit rate) can result in degradation of the new data stream and/or the existing VBR data stream.
Further, an admission control function is typically executed each time a new real-time data stream requests admission to a network. Depending on the types of probing techniques included in an admission control function, the admission control function can take some amount of time (e.g., up to three seconds) to complete. During the time the admission control function is executing, a user may be prevented from utilizing a computer system for desired purposes. For example, a user may be prevented from watching a television program until admission control for the real-time data stream carrying the television program has completed. Thus, each time a user desires to start a real-time data stream, the user would have to wait for the admission control function to complete. Waiting for an admission control function to complete degrades a user's experience.
The combined waiting time for admission control functions can further degrade a user's experience when the user frequently starts and stops data streams. Even if a user frequently starts and stops the same data streams (e.g., turning a stereo on and a television off), the complete admission control process if performed each time a data stream (even the same data stream) requests admission to the network. Therefore systems, methods, and computer program products for enhancing admission control for data streams would be advantageous.